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ABSTRACT 



DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93943-5101 



The Campaign Planning Exercise (CAMPEX) War Game is being used for the 
training of the students of the Air War College in the area of the Air Campaign Planning 
and the Ground Forces Deployment. The CAMPEX life cycle started in 1986 and the last 
version was released in 1994. Microsoft Basic Version 7.10 Professional Development 
System was used for its development. CAMPEX was not designed or developed with the 
objected-oriented technique, so further extension and its use as component for Distributed 
Components Applications is not feasible. 

TRADOC Analysis Center (TRAC) of Monterey plans to use a collection of old 
War Games as Components of a Distributed Embedded Application. The CAMPEX 
Employment Module is the first War Game that will form one of the components of this 
application, so the redesign and implementation of CAMPEX Employment Module with 
object-oriented technique is necessary. This thesis examines the distributed component 
architectures available to support the Distributed Embedded Application, re-engineers the 
CAMPEX Employment Module into an object-oriented design, and validates its 
requirements via a prototype developed using ACCESS2000. The new design will be the 
basis for reengineering the other war game planning software for the Air War College. 
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I. INTRODUCTION 



A. GENERAL 

There has been continuous progress in the development of computers over the 
past four decades. The results are more impressive by any measure in the state of 
hardware than in the state of software. From the beginning hardware developers have had 
a theoretical basis that comes from other sciences, like mathematics, physic, mechanics, 
etc. Also, the hardware developers borrowed and applied standard methods from other 
engineering disciplines for design and manufacturing. In contrast, software developers 
initially relied primarily upon human imagination, invention, and ingenuity. This lack of 
an engineering approach has produced legacy software applications that cannot be 
supported any longer. 

As the science of software development slowly evolved into a distinct engineering 
discipline, software engineers established the processes, the techniques and the rules that 
govern the development of software systems. 

The process to develop a software system usually consists of the following 
phases': Requirements Analysis, Functional Specification, Architectural Design, 
Implementation and Evolution. In the nineties the object-oriented methodology has 
emerged as the most popular method because it supports the rule that can be described by 
the maxim, "reduce, reuse recycle". The object-oriented methodology increases 
efficiency, reduces development time and decreases the cost of software products. 

1 Berzins and Luqi in their book "Software Engineering with Abstractions" 1990 chapter 1 p 6 about the 
Software Development Process 



1 



Software engineering has also changed the process of software evolution and 
maintenance. The old approach "to maintain a software system for period of time and 
then to replace it with an complete new system" when further evolution is not feasible is 
not an efficient solution. It is too costly to lose the assets that an existent and working 
system offers, including all the previous work that went into the requirements analysis 
phase. Also, users have verified the existent system over time and have gained 
knowledge about the system’s operations through years of maintenance and development. 
To be efficient, the evolution technique ' for an existent system must respect that the 
current system is valuable even though it is increasingly difficulty to extend. Therefore, 
the new approach must respect the assets of the old system and developers should salvage 
any useful parts from the old system and change only the parts that must be changed. 

The most common problem when re-engineering old systems is that they are not 
implemented according to modem, evolvable methods like the object-oriented design 
techniques; however, the developers can still use the requirements specification of the old 
systems in the first phase of the redesign. So the designers must retrieve the requirements 
specification from the old system and document them with object-oriented techniques. In 
addition, the most effective approach to redesign is to implement a prototype. In this way, 
the designer can verify the correctness of the requirements specification and design 
through reviews with the customer. 

Current software engineering techniques are well supported by commercial-off- 
the-shelf (COTS) products. Today COTS products are increasingly important and highly 
economical tools for organizations to explore reengineering opportunities and strategies. 
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The ultimate goal is to reengineer the old system using object-oriented techniques that 
allows the concurrent evolution of software via component-based development. 

B. MOTIVATION 

The TRADOC Analysis Center of Monterey, California plans to redesign and re- 
implement the Campaign Planning Exercises (CAMPEX) discussion war game. The 
CAMPEX 2 is a software system that was implemented by the Air War College to provide 
students the opportunity to test their understanding of strategy, leadership, international 
security. National Security Decision Memorandums (NSDM), General Purpose (GP) 
forces, unified commands, and joint fundamentals. The current version of the CAMPEX 
system consists of two modules, the "Deployment" and the "Employment". In the 
"Deployment" module the student deploys joint forces and in the "Employment" module 
he employs the forces. 

The CAMPEX system lifecycle began in 1986 and the current version (with ED 
8.9 3 ) was released in 1994. Because CAMPEX is still used today, we can assume that it 
satisfies most requirements of the Air War College. Moreover, we can conclude that the 
system requirements and the algorithms and other functions of CAMPEX have been 
verified in practice, because the CAMPEX was developed, maintained, and used by Air 
War College personnel. CAMPEX was implemented in the Microsoft Basic Professional 
Development System Version 7.10, and the object-oriented techniques were not used for 



2 Air War College in the CAMPEX User Manual 

3 Air War College Source Code of CAMPEX last version 
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its design. Also, a serious problem for further evolution of CAMPEX is the lack of 
documentation for any phase of its development. 

An important constraint that must be satisfied when reengineering a current 
software system is the available hardware. Today the user has PC’s with greater 
processing power and data storage capacity that often operate on a high capacity network. 
The reengineering of CAMPEX must account for this computing environment. 

The final factor that must be considered when reengineering CAMPEX is the 
High Level Architecture (HLA) for distributed simulations. The U.S. Department of 
Defense DoD) mandates use of the HLA in new simulations and the retrofit of legacy 
simulations by 2001. 

C. OBJECTIVES 

This thesis describes the reengineering of the CAMPEX "Employment" Module 
using object-oriented techniques with respect to the current user’s needs in combination 
with the current available hardware. The secondary goal is preparation for High Level 
Architecture compliance should the user decide to distribute CAMPEX over the network. 

So the primary objectives of my work were twofold: 1) research in the area of the 
Distributed Objects Architectures and 2) analysis and redesign of the CAMPEX 
"Employment" module with object-oriented techniques and verify the design with a small 
prototype. The prototype must work in the Microsoft Windows environment and allows 
user to run some of the CAMPEX procedures through Internet. 
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D. THESIS ORGANIZATION 

Chapter II provides: 

background on Distributed Objects Architectures, 

high level requirements for the Distributed Components, 

a brief description of the partial and "complete" existent solutions in this area, 

the advantages and disadvantages of each solution, and 

the common characteristics and differences. 

Chapter III provides the requirements analysis and functional specification of 
CAMPEX Employment that results from reverse engineering the current version. The 
requirements analysis and functional specification are documented using Unified 
Modeling Language (UML) notation. 

Chapter IV describes the new design and architecture of the new CAMPEX using 
the UML methodology and notation. The existing CAMPEX algorithms and functions are 
the basis for the design of the object interactions because the Air War College has already 
verified them in practice. 

Chapter V presents the prototype implementation. The prototype is implemented 
with ACCESS-2000 and Visual Basic. Chapter V contains the basic database design, 
queries and forms. Moreover, this chapter offers a "User Manual" that allows the user to 
test and use the prototype easily. 

Chapter VI summarizes the key elements of the thesis, provides observations 
about the difficulties and lessons learned, and provides insights and recommendations for 
future work to apply the selected Distributed Objects Architecture and to re-implement 
the entire CAMPEX. 

5 
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II. DISTRIBUTED COMPONENTS ARCHITECTURE 



A. THE PROBLEM DESCRIPTION 

Even after many years the state of the art and science in software development is 
not as satisfactory as that in hardware development. Different vendors have developed 
numerous remarkable applications using various methods, computer languages, and 
platforms. The exploitation of all these old applications in combination with new 
applications under development on different types and configured machines that run over 
Internet poses one of the biggest challenges in the software engineering today. 

B. REQUIREMENTS AND CONSTRAINTS 

This section addresses the high-level requirements and constraints to solve the 
problem posed in the previous section. First the object-oriented methodology for 
software implementation comprises a requirement for new applications and a constraint 
for existing applications. This general requirement 4 is that 

• the applications must consist of components, 

• the components should be characterized by high cohesion and loose coupling, 

• the components should be developed in accordance with object-oriented 
principles (encapsulation, polymorphism and inheritance), and 

• the components should communicate through messages. 



4 Reaz Hoque and Tarun Sharma in their book "WEB Components" 1998 chapter 1 p 7 what are the 
Distributed Objects 
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The second requirement is to cross network boundaries. The new architecture 
must allow the users to utilize applications that consist of components that can be 
distributed on different machines on WANs or LANs. This requirement demands that the 
application access the network in standard ways and expand its address space to the entire 
network effectively. 

The third requirement is that the components should be programming language 
independent. That is, components that are developed in different programming languages 
be able to interoperate in a distributed system. At the same time the user must be able to 
choose a unique tool for the creation and the integration of these heterogeneous 
components. 

The fourth requirement is to cross the platform boundaries. The new architecture 
must allow the old legacy applications as well as the new ones to run on machines of 
different type or configuration. In other words, machines and their operating system 
should not block communication among the components of the distributed application. 

The fifth requirement is to satisfy the "reduce, reuse, recycle" dictum. This 
requires that the application be reusable as a whole or in parts (patterns, components or 
objects). The application must be designed so that it can be deployed in an environment 
with diminished resources and function in a reduced, but useful, capacity. Finally, it 
must provide components and design features that can be recycled for the production of 
new applications. 

The sixth and last requirement is that the application must offer a satisfactory 
level of performance and reliability. This constraint follows directly from the maxim to 
"reduce". "Reduce" excludes solutions that increase the implementation time and 
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complexity. This excludes many popular solutions that are used today. Examples include 
the 4GL languages with fat clients, the development of low level drivers and new 
network protocols for the crossing of network boundaries, and the use of different tools 
with each programming language for breaching the programming language barriers. 

A final constraint is that the new system should demand no new resources. 

C. DISTRIBUTED COMPONENTS SERVICES 

Today many vendors have software development solutions that seem to satisfy all 
these requirements. These solutions are variants of the Distributed Components Based 
Architecture. All the vendors contend that they have realized the early dream of the 
software community for distributed computing that properly uses all the capabilities of 
the current hardware. 

Distributed architectures must offer the following services 5 : 

• naming service to provide a mechanism for locating distributed components in 
a system, 

• monitor service to watch the whole system for correctness and alert if 
something wrong happens to an operator, 

• listening service to ensure that users of the distributed components have the 
appropriate privileges, 

• persistence mechanism to uniformly save, update, and restore an object’s state 
using a persistent data store, 



5 SUN Microsystems in JINI Architecture Specification version 1.0.1 1999 about Distributed Components 
Services 
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• transaction support mechanism to ensure that a transaction is completed or 
aborted in its entirety whenever work is performed. (Typically a transaction 
defines an atomic unit of work in an enterprise system. A distributed 
transaction is a single unit of work that spans multiple computers.) 

• security mechanisms to ensure that communication from authorized users to a 
distributed object is secure, 

• tnessaging support to provide an asynchronous programming model, as 
opposed to the typical request-reply model. (There are many types of 
applications that require messaging. An example is an application in which the 
client and server are required to run in different times.) 

• distributed services to automatically deallocate distributed objects when they 
are no longer being used by their clients, and 

• resource management to manage distributed objects in such a way as to 
maximize scalability and support a large number of clients interacting with a 
large number of distributed objects in short period of time. 

D. EXISTING PARTIAL SOLUTIONS 

Today there are many suggestions from different vendors. Some of these 
suggestions tackle the problem of the distributed computing by trying to satisfy all the 
requirements and others by trying primarily to satisfy an individual requirement. 

The following techniques suggest solutions for various requirements of the distributed 
computing problem: 
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The Remote Procedure Call Mechanism 6 satisfies the requirement to cross network 
boundaries. It is probably the most popular technique for crossing network barriers. At 
first sight it seems well suitable for distributed computing since it allows one 
application to make functions calls through the network. However, if we examine 
RPC deeper we find that RPC does not allow the objects to change state. Adding this 
capability has a very large performance cost. 

Sockets mechanisms 7 are another way to cross network barriers. This solution has 
many advantages, but it usually demands low-level network programming. To be 
useful for distributed computing architectures this solution should offer network 
interfaces that hide all the unnecessary low level networking details. 

o 

Interpreted Languages can solve the problem of the crossing operating system (OS) 
boundaries. Since this kind of languages is not compiled to a specific binary format, 
they can be reused and run in source code format on multiple machines. The drawback 
of this solution is the lack of speed because interpreted code is typically hundreds of 
times slower than the compiled code; also, the interpeter may not exists for some 
platforms. 

Binary Compatibility Layers can be used to cross OS barriers. This solution provides a 
layer of code on top of the OS that runs binary files compiled for a different OS. This 
solution is feasible if binary compatibility layers exist for all the OS’s. One problem 
with this solution is that it demands a lot of work from programmers. Another 

6 Gopalan Suresh Raj in his book "A Detailed Comparison of CORBA, DCOM and JAVA/J1NI 

7 Reaz Hoque and Tarun Sharma in their book "WEB Components" 1998 chapter 1 p.14 what are the 

Distributed Objects 
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